Connection (session) rate numbers are used to rate the capacity and capability of a Security Device, such as a router. It refers to the number of sessions that can be established within a particular time interval. These numbers directly depend on how quickly a rule set can be searched. Security Applications are programmed with a set of access control rules, other types of rule sets, and/or policies set by the Administrator (collectively, any such access rules or policies are referred to herein as Access Control Lists (ACLs). The security device consults the configured ACLs to determine whether the packet should be allowed or denied and the processing that needs to be applied to the packet.
The ACLs are maintained in a prioritized order so that the first rule in the ACLs that matches an incoming packet is the rule that is used with no further rules in the ACLs needing to be checked. The ACLs may be maintained as a single rule table or in multiple tables. IP Tables are generally organized in multiple tables. A rule match occurs when the Source IP, Destination IP, Source Port, Destination Port and Protocol of a packet matches with the highest priority configured rule in the ACLs. When a rule match occurs that allows a packet, a session is typically created so that the remaining packets of that particular session need not go through ACL policy lookup. The five tuples of the packet are added to a session table that is maintained in the memory of the security device.
The security device applications are typically architected in a Control Plane/Data Plane Model. The Control Plane (CP) holds the ACL rule set and performs rule checks while the Data Plane (DP) performs the packet processing. When a packet arrives at the security device, the DP consults the session table to determine whether a session has already been established for the session. If a session is not found, the DP sends an exception packet to the CP. The CP then checks the ACLs against the packet to determine if packets belonging to the session should be allowed at the security device. In some cases, the CP consults multiple rule tables included in the ACLs before creating a session in DP. For example, in the case of IP tables, five tables are generally consulted, some of the tables are consulted multiple times (these tables include the Filter table, the NAT table, the Mangle table, the Raw table, and the Security table).
If, after consulting the ACLs, the CP decides to allow the packet, then the CP pushes the session to the DP which updates the session table. The DP processes subsequent packets for the session till the session expires, without subsequent packets having to go through the CP. Because of the many rule lookups performed during CP processing, a bottleneck occurs when processing a packet that does not yet have an established session.
Approaches such as Policy de-correlation or alternate arrangement of rules have been used to improve connection rate performance. However, these approaches have drawbacks. These approaches consume a great deal of memory to store the de-correlated set. In addition, these approaches require additional processing time to re-compile the de-correlated set whenever rules are added, modified, or deleted. Consequently, these existing implementations that have memory and processing constraints continue to experience a performance issue during connection establishment.